home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re More on Stack Crash... < prev    next >
Encoding:
Internet Message Format  |  1996-07-01  |  3.4 KB  |  [TEXT/ttxt]
  1. Subject:     Re:More on Stack Crash...
  2. Sent:        6/28/96 9:25 AM
  3. Received:    7/1/96 8:34 AM
  4. From:        Greg Friedman, friedman@cognosis.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. At 9:26 PM 6/27/96, The3Furies@aol.com wrote:
  9. > I just found some new info on my stack crash - it is dying in another
  10. > part's code.  Lets call the part I'm creating stationery for Part A
  11. > (a container) and the other Part B (a non-container).
  12.  
  13. During stationery creation, there shouldn't be any "other part's code" to
  14. reference.
  15.  
  16. > I reference Part B directly from my code in Part A (I include the .xh
  17. > and get the part from the embedded frame.  I also include Part B
  18. > in my project as a library <- a mistake???), but this only happens
  19. > when a Part B is actually embedded.  I have noticed that since doing
  20. > this, the debugger does not load the sym file etc when I first drop
  21. > a Part B into Part A.  Do I need to explicitly load the SOM part
  22. > for Part B from Part A at some point?  Since I didn't load the part,
  23. > how did it get into my stack to begin with?  Is the CFM trying to
  24. > release a fragment that never actually got loaded?  I am confused...
  25. > and now you probably are too.
  26.  
  27. I'm not sure I understand what you are doing here.  Why are you including
  28. the other part's .xh? Parts should always reference other parts via their
  29. ODPart API. If you are trying to add additional methods to the SOM
  30. interface of one of your parts, and call those methods directly from
  31. another of your parts, I suggest you do not do this. You should, instead,
  32. use extensions. Your client part should call your server parts HasExtension
  33. and AcquireExtension methods. This shouldn't require access to your server
  34. part's .xh file, since these methods are defined in the .xh file of ODPart.
  35.  
  36. Your client part needs to link against _something_ that exports the class
  37. data for the extension you are trying to write. The best way to do this is
  38. to create a shared library (not a part, just a shared library) that
  39. implements the extension and exports the extensions class data symbol
  40. (remember that with SOM, you should never export all of the methods of SOM
  41. objects, just their class data symbol).
  42.  
  43. There are two basic approaches that work for implementing extensions in
  44. standalone libraries. The first is to implement the extension in the shared
  45. library such that when an extension is created, it is initialized with a
  46. collection of callbacks into the part that creates it. The callbacks should
  47. be simple C methods, defined in "extern "C"" scope to prevent name
  48. mangling. They should not be exported by the part. When a method of the
  49. extension is called, it makes a callback into the part, which does the
  50. right thing. I like this method.
  51.  
  52. The other approach is to implement the standalone library as an abstract
  53. base class. With this implementation, you must create a uniquely named SOM
  54. subclass of the extension for every server part you write. The server part
  55. then statically links the SOM subclass. Client parts link against the
  56. standalone library, they do not need to link against the server part.
  57.  
  58. In both cases, client parts should weaklink against the extension library.
  59. This will enable them to run if the shared library isn't installed.
  60.  
  61. Hope this helps,
  62.  
  63. gsf.
  64.  
  65.  
  66. _________________________________________________________
  67. Greg Friedman      ODF Engineering       Apple Computer
  68.  
  69.